Component-Based Systems: A Classification of Issues

D eveloping and using various component forms as building blocks can significantly enhance software-based system development and use, which is why both the academic and commercial sectors have shown interest in component-based software development. Indeed, much effort has been devoted to defining and describing the terms and concepts involved. Briefly, we describe software components as units of independent production, acquisition, and deployment that interact to form a functional system. See the “What Is a Component?” sidebar for a detailed definition and description of a component. In this article, we identify a set of issues organized within an overall framework that software developers must address for component-based systems (CBS) to achieve their full potential. Participants in the 1999 International Workshop on Component-Based Software Engineering (http://www.sei.cmu.edu/cbs/icse99/ cbsewkshp.html, Aug. 1999) developed a framework similar to ours, which helps validate our model. In component-based development, although significant difficulties can arise from the inexact notion of a component, maintaining at least a semi-vague notion of a component can be valuable. Doing so helps avoid a so-called “technology lock-in,” which narrows the scope of our thinking. Components can take a wide range of forms and sizes; they should be independent of specific software architectural style; while objects may be components, all components are not objects. Therefore, our framework leads to a more effective understanding of components because it helps clarify those aspects of the component concept that are largely independent of architectural and implementation issues. Classifying and grouping the relevant ideas into a framework achieves the following: